For Infinity-sized containers, updateBounds() skips super.updateBounds() but does not clear/reset the existing bounds before aggregating child bounds. Since non-finite bounds are initialized with max = Infinity, subsequent bounds.addBounds(childBounds) will keep the container bounds infinite and won’t become child-derived. Clear/reset bounds (or start from the first child bounds with clear=true) when !this.isFinite() and enableChildBoundsUpdate is enabled.

ImageLayer.onActivateEvent() dereferences this.parentApp immediately. Container.addChild() invokes onActivateEvent even when the container tree is not attached to a root/world container, so parentApp may be unavailable and this will throw. Add a guard (throw a clear error or defer initialization until attached) before using parentApp.viewport/renderer.

enablePointerEvent() uses _app.renderer.getCanvas() as the default event target, but _app is only assigned via the GAME_INIT event. If bindPointer() / registerPointerEvent() is called before an Application is constructed, this will crash. Add a defensive check and throw a clear initialization error when _app is undefined.

The constructor registers global resize/orientationchange/scroll listeners via globalThis.addEventListener(...), but destroy() does not remove them. Creating/destroying multiple Application instances will leak listeners and duplicate emitted events. Store handler references and unregister them in destroy().

TMXTileMap.addTo() resolves const app = container.getRootAncestor().app; unconditionally. If container is not attached to a root/world container, getRootAncestor() can return undefined and this will throw even when setViewportBounds is false. Move app resolution inside the setViewportBounds === true branch and add a defensive check when no root/app is available.

Application.init() assigns screen.orientation.onchange directly and destroy() unconditionally clears it. This can clobber another Application instance’s handler (or any consumer handler) when multiple apps exist or when an app is destroyed out of order. Prefer screen.orientation.addEventListener('change', ...)/removeEventListener, or only clear onchange if it still equals this instance’s handler (restore previous handler otherwise).

destroy() sets screen.orientation.onchange = null without checking whether another Application (or user code) has since installed a different handler. This can break orientation handling in multi-app scenarios. Only clear it if the current value matches this instance’s handler, or switch to add/removeEventListener for ScreenOrientation change events.

The repeat setter no longer triggers a resize / pattern rebuild. If repeat is changed at runtime after activation, width/height and _pattern can become inconsistent until a viewport resize happens. Consider updating size (this.resize(viewport.width, viewport.height)) and recreating the pattern when parentApp is available and the layer is active.

The doc/comment says the container anchorPoint is “always” (0,0) / “treated as” (0,0), but nothing prevents users from changing anchorPoint after construction (which can reintroduce Infinity * anchor issues). Consider clarifying this as a default (not an invariant), or enforcing it (e.g. override setter / clamp to 0 when width/height are non-finite).

In this example, backgroundColor passed to new Application(...) only affects the parent element CSS background (per ApplicationSettings docs), while app.world.backgroundColor.parseCSS(...) controls the rendered clear color. Having both (and the comment “set a gray background color”) is confusing—consider either removing the option or adjusting the comments to reflect the distinction.

The updated JSDoc for boot() says it’s “called automatically by the Application constructor”, but the entrypoint still auto-calls boot() on DOMContentLoaded when skipAutoInit is false (see src/index.ts). Consider updating the doc to reflect both auto-init paths (DOMContentLoaded + Application.init/constructor) so users relying on skipAutoInit aren’t misled.